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Preface 

This document was generated in support of NASA contract NAS1-18586, Design and Validation 
of Digital Flight Control Systems Suitable for Fly-By-Wire Applications, Task Assignments 8. 
Task 8 is associated with formal verification of embedded systems. 

The principle emphasis of the work described in this report is to develop a methodology to 
formally verify correct synchronization communication of devices in a composed hardware system. 
Previous system integration efforts have focused on vertical integration of one layer on top of 
another. This task examines "horizontal" integration of peer devices. To formally reason about 
communication, we mechanize a process algebra in the HOL theorem-proving system. Using this 
formalization we show how four types of device interactions can be represented and verified to 
behave as specified. The report also describes the specification of a system consisting of an AVM- 
1 microprocessor and a memory management unit, which have been verified in previous work. A 
proof of correct communication is presented and the extensions to the system specification to add a 
direct memory device are discussed. 
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1.0 INTRODUCTION 


Hardware systems consist of many composed, hardware devices that communicate with 
one another. This report describes a methodology to formally verify the correctness of the 
synchronization communication within a hardware system. The methodology is based on 
the formalization of a process algebra within the HOL theorem-proving system. Using this 
formalization, we show how four types of device interactions can be represented and proven 
to behave as specified. 

The report also includes a specification of a system consisting of an AVM-1 micro- 
processor and a memory management unit (MMU). These devices have been verified in 
previous work (refs. 1 and 2). A correctness proof for the communication between the mi- 
croprocessor and MMU is presented and an extended system specification, which includes 
a direct memory access device (DMA), is discussed. 

Previous system integration efforts have focused on vertical integration of one layer on 
top of another. This work examines the “horizontal” integration of communicating devices. 
Device communication may require only a single message or a series of messages to be passed 
between two devices. The types of interactions can be loosely described as belonging to one 
of the following categories: remote procedure call, process creation (fork), message passing, 
or rendezvous. At a lower level, the information is passed over a bus using a hardware 
protocol (e.g., 4-phase handshaking). 

To demonstrate how system integration can be achieved, we will show how several 
devices can be composed to form a system that uses the communication protocols described 
above. For example, the CPU and MMU interact in a remote procedure call manner. The 
CPU sends a memory request to the MMU and waits for the response. The CPU and 
DMA interact in a manner similar to process creation followed by a rendezvous. 

The descriptions of devices are frequently large and the proofs of these devices can 
require significant amounts of CPU time. For example, the proof of a single microprocessor 
microinstruction can require 24 hours of CPU time. To reason about composed devices, 
many details must be abstracted away. Further, the modeling and verification of concurrently 
executing and communicating devices is quite difficult. 
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Process algebras and concurrency theories seek to provide formal models that aid in 
our understanding of the behavior of such systems. The archetype for the process algebra 
developed in this report, is the Calculus of Communicating Systems (CCS) (ref. 3). Despite 
the seemingly simple syntactic definition of CCS, the semantics of its primitive operators are 
carefully defined and allow complicated communication schemes to be accurately represented. 
CCS provides only a single mechanism for processes to synchronize, but Milner asserts that 
shared memory, pipes, channels, and procedural rendezvous can all be expressed in terms of 
this simplest form of communication (ref. 4). 

This report describes our approach to verifying composed hardware systems and presents 
a mechanized process algebra for formally reasoning about device interactions. Section 2 
discusses formal verification, the HOL theorem proving system, and related work. Section 
3 describes process algebras and presents a description of the operational and transitional 
semantics for CCS. The mechanization of the process algebra within the HOL theorem 
proving system is presented in Section 4. Section 5 presents specification and verification 
examples using the formalized process algebra, including a CPU-MMU composition proof. 
The final section summarizes this work and describes future extensions. 
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2.0 BACKGROUND 


2.1 HARDWARE VERIFICATION 

Hardware verification requires that the design of a system is formally shown to satisfy its 
specification through a mathematical proof. Using theorem- proving techniques, an expres- 
sion describing the behavior of a device is proven to be equivalent in some sense to an 
expression describing the implementation structure of the device. These expressions con- 
cisely describe the behavior of devices in an unambiguous way. An additional benefit of 
hardware verification is that the behavioral semantics of the hardware are clearly defined. 
This provides an accurate basis for building correct software systems (ref. 5). 

Verification is expensive and requires a substantial amount of time. While all develop- 
ment efforts would benefit from the use of formal methods, presently only the verification of 
life-critical and security properties merits the expense. Tools such as HOL are still under 
development. The theory libraries are not yet sufficient for general use. Further, techniques 
and methodologies to verify large systems are not available. 

Circuits and devices are described in HOL using a mixture of functions and predicates. 
Universally quantified variables are used to specify input and output device lines while 
internal device lines are existentially quantified. The specifications are generally defined to 
model a state transition system. A specification defines the state and environment at time 
t+1, as a function of the state and environment at time t. 


2.2 RELATED WORK 

Newman proposes a unified hierarchy that accommodates all critical requirements (ref. 6). 
Responsibility to satisfy each requirement can then be delegated to an appropriate layer 
of the design. The layers remain interdependent; the more abstract layers relying on the 
correctness of the lower levels. Formal proofs about the hardware-level discharge some of 
the assumptions made by higher, software levels. Similarly, hardware-level proofs often 
make assumptions about the behavior of the software which are discharged when the level 
is composed (ref. 7). 
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Hardware verification efforts thus far have focused primarily on a microprocessor as 
the base for computer systems (refs. 8, 9, 10 and 11). Perhaps the best known verifica- 
tion effort is that of the VIPER microprocessor (refs. 9, 12 and 13). VIPER is the first 
microprocessor intended for commercial distribution where a formal verification has been 
attempted. However, these processors are quite limited. The processors verified have mod- 
eled small instruction sets and, generally, have not included modern CPU features such as 
pipelines, multipled functional units, and hardware interrupt support. Tamarack-3 (ref. 8) 
and AVM-1 (ref. 14) do provide sufficient interrupt support to connect with an inter- 
rupt controller. However, no system currently verified provides the memory management 
functions necessary to support a secure operating system. 

Previous efforts to verify systems have attempted to construct vertically verified sys- 
tems with a microprocessor /memory as the system base. Joyce has verified a compiler level 
whose target machine description is the specification of the verified Tamarack-3 micropro- 
cessor (ref. 15). Computational Logic Inc. has verified a “stack” of interpreters where the 
implementation of a level is the specification of the next lower level (ref. 5). The stack 
consists of a compiler (Micro-Gypsy) an assembler and linking loader, and a microprocessor. 
The operating system, KIT, is not part of the verified stack. The KIT project designed and 
verified an operating system that supports multiple processes and asynchronous I/O. User 
processes are able to communicate only through message passing, which is implemented by 
the kernel. This ensures that tasks are isolated from one another. However, the hardware 
base has not been designed nor verified. Bevier assumes extensions to the FM8502 mi- 
croprocessor (ref. 11) to provide interrupts, asynchronous I/O, memory management and 
supervisor- mode instructions. 

2.3 THE HOL THEOREM PROVER 

HOL is a general theorem-proving system developed at the University of Cambridge (refs. 16 
and 17) that is based on Church’s theory of simple types, or higher-order logic (ref. 18). 
Church developed higher-order logic as a foundation for mathematics, but it can be used 
for describing and reasoning about computational systems of all kinds. Higher-order logic 
is similar to the more familiar predicate logic, but allows quantification over predicates and 
functions, not just variables, allowing more general systems to be described. 
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HOL grew out of Robin Milner’s LCF theorem prover (ref. 19) and is similar to other 
LCF progeny such as NUPRL (ref. 20). Because HOL is the theorem-proving environment 
used in the body of this work, we will describe it in more detail. 

HOL’s proof style can be tailored to the individual user, but most users find it conve- 
nient to work in a goal-directed fashion. HOL is a tactic-based theorem prover. A tactic 
breaks a goal into one or more subgoals and provides a justification for the goal reduction 
in the form of an inference rule. Tactics perform tasks such as induction, rewriting, and 
case analysis. At the same time, HOL allows forward inference and many proofs are a 
combination of both forward and backward proof styles. Any theorem-proving strategy a 
user employs in connection with HOL is checked for soundness, eliminating the possibility 
of incorrect proofs. 

HOL provides a metalanguage, ML, for programming and extending the theorem 
prover. Using ML, tactics can be put together to form more powerful tactics, new tac- 
tics can be written, and theorems can be combined into new theories for later use. The 
metalanguage makes the HOL verification system extremely flexible. 

In HOL all proofs, even tactic-based proofs, are eventually reduced to the application 
of inference rules. Most nontrivial proofs require large numbers of inferences. Proofs of 
large devices such as microprocessors can take many millions of inference steps. In a proof 
containing millions of steps, what kind of confidence do we have that the proof is correct? One 
of the most important features of HOL is that it is secure, meaning that new theorems can 
only be created in a controlled manner. HOL is based on five primitive axioms and eight 
primitive inference rules. All high-level inference rules and tactics do their work through 
some combination of the primitive inference rules. Because the entire proof can be reduced 
to one using only eight primitive inference rules and five primitive axioms, an independent 
proof-checking program could check the proof syntactically. 


2.3.1 THE LANGUAGE. 

The object language of HOL is described in this section. We will discuss HOL’s terms and 
types. 
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Terms. All HOL expressions are made up of terms. There are four kinds of terms in 
HOL: variables, constants, function applications, and abstractions (lambda expressions). 
Variables and constants are denoted by any sequence of letters, digits, underlines, and primes, 
starting with a letter. Constants are distinguished in the logic; any identifier that is not a 
distinguished constant is taken to be a variable. Constants and variables can have any finite 
arity, not just 0, and, thus, can represent functions as well. 

Function application is denoted by juxtaposition, resulting in a prefix syntax. Thus, a 
term of the form "tl 1 2” is an application of the operator tl to the operand t2. The term s 
value is the result of applying tl to t2. 

An abstraction denotes a function and has the form "A x . t". An abstraction A x . t 
has two parts: the bound variable x and the body of the abstraction t. It represents a 
function, f, such that ”f(x) « t". For example, " A y. 2*y" denotes a function on numbers 
that doubles its argument. 

Constants can belong to two special syntactic classes. Constants of arity 2 can be 
declared to be infix. Infix operators are written "randl op rand2" instead of in the usual 
prefix form: "op randl rand2". Table 2.3-1 shows several of HOL’s built-in infix operators. 


Table 2.3-1: HOL Infix Operators 


Operator 

Application 

Meaning 

= 

tl * t2 

tl equals t2 

» 

tl ,t2 

the pair tl and t2 

A 

tl A t2 

tl and t2 

V 

tl V t2 

tl or t2 


tl =» t2 

tl implies t2 


Constants can also belong to another special class called binders. A familiar example 
of a binder is V. If c is a binder, then the term "c x.t" (where x is a variable) is written as 
shorthand for the term "c(A x. t)". Table 2.3-2 shows several of HOL’s built-in binders. 

In addition to the infix constants and binders, HOL has a conditional statement that 
is written a — » b | c, meaning “if a, then b, else c.” 
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Table 2.3-2: UHL Binders 


Binder 

Application 

Meaning 

V 

V X. t 

for all x, t 

3 

3 x. t 

there exists an x such that t 

£ 

£ X. t 

choose an x such that t is true 


Types. HOL is strongly typed to avoid Russell’s paradox and others like it. Russell’s 
paradox occurs in a higher-order logic when one can define a predicate that leads to a 
contradiction. Specifically, suppose that we define P as P(x) ■ ->x(x) where -» denotes 
negation. P is true when its argument applied to itself is false. Applying P to itself leads 
to a contradiction since P(P) * -, P(P) (i.e. , true = false). This kind of paradox can be 
prevented by typing since, in a typed system, the type of P would never allow it to be applied 
to itself. 

Every term in HOL is typed according to the following recursive rules: 

a. Each constant or variable has a fixed type. 

b. If x has type a and t has type (3, the abstraction A x. t has the type (a — ► /?). 

c. If t has the type (a — ► /?) and u has the type a , the application t u has the type /?. 

Types in HOL are built from type variables and type operators. Type variables are 
denoted by a sequence of asterisks (*) followed by a (possibly empty) sequence of letters and 
digits. Thus, *, ***, and *ab2 are all valid type variables. All type variables are universally 
quantified implicitly, yielding type-polymorphic expressions. 

Type operators construct new types from existing types. Each type operator has a 
name (denoted by a sequence of letters and digits beginning with a letter) and an arity. If 
(Ti, . . . ,a n are types and op is a type operator of arity n, the (<r 1} <r n )op is a type. Note 
that type operators are postfix while normal function application is prefix or infix. A type 
operator of arity 0 is a type constant. 

HOL has several built-in types, which are listed in Table 2.3-3. The type operators 
bool, ind, and fun are primitive. HOL has a special syntax that allows (*,**)prod to be 
written as (* # **), (*,**)sum to be written as (* + **), and (*,**)fun to be written 
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Table 2.S-S: HOL Type Operators 


Operator 

Arity 

Meaning 

bool 

0 

booleans 

ind 

0 

individuals 

num 

0 

natural numbers 

(*)list 

1 

lists of type * 

(*,**)prod 

2 

products of * and ** 

(* ,**)sum 

2 

coproducts of * and ** 

(* ,**)fun 

2 

functions from * to ** 


as (* -> **). 

2.3.2 THE PROOF SYSTEM. 

HOL is not an automated theorem prover but is more than simply a proof checker, falling 
somewhere between these two extremes. HOL has several features that contribute to its use 
as a verification environment: 

a. Several built-in theories, including booleans, individuals, numbers, products, sums, 
lists, and trees. These theories contain the five axioms that form the basis of higher- 
order logic as well as a large number of theorems that follow from them. 

b. Rules of inference for higher-order logic. These rules contain not only the eight basic 
rules of inference from higher-order logic, but also a large body of derived, inference 
rules that allow proofs to proceed using larger steps. The HOL system has rules that 
implement the standard introduction and elimination rules for Predicate Calculus as 
well as specialized rules for rewriting terms. 

c. A collection of tactics. Examples of tactics include: REWRITE-TAC which rewrites a goal 
according to some previously proven theorem or definition; GEN-TAC which removes 
unnecessary universally quantified variables from the front of terms; and EQ.TAC which 
replaces a goal of the form P <*=» Q with two subgoals, P =» Q and Q => P 

d. A proof management system that keeps track of the state of an interactive proof session. 
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e. A metalanguage, ML, for programming and extending the theorem prover. Using the 
metalanguage, tactics can be put together to form more powerful tactics, new tactics 
can be written, and theorems can be aggregated to form new theories for later use. 
The metalanguage makes the verification system extremely flexible. 

2.4 INTERPRETERS 

The interpreter model, as defined in (ref. 14), can be used to describe state-transition 
systems. Interpreters can be differentiated from other models by their monolithic treatment 
of state and their flat control structure. The interpreter selects one of a fixed set of actions 
based upon the current state and returns a new state. The model incorporates four parts: 

• A representation of the state S. 

• A set of state transition functions defining the denotational semantics for each inter- 
preter action (instruction) : S\ x Env — ♦ Sj. 

• A next state function that selects an appropriate state transition function given the 
current state K : Sj — > J\. 

• A function I, relating the state at time f + 1 to the state and environment at time t 
using K and J. 


I[s y e] = s(t + 1) = (K(s t))(s t)(e t) 

Correctness is a relation between a specification and implementing interpreter such that: 

of) 

where / is a temporal abstraction function relating the differing specification and implemen- 
tation time granularities. The state space s n and environment e n are abstractions of the 
implementing state space s m and environment e m , respectively. 

Devices that provide a set of instructions such as a CPU or FPU can easily be modeled 
as interpreters. Other devices, such as a programmable interrupt controller (PIC) or DMA, 
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can also be modeled as interpreters with instructions. For example, we can model a PIC as 
an interpreter with instructions to: 

• update the state due to an environment request. 

• update a local register. 

• provide status information. 

• initiate communication with CPU. 

A memory management unit can also be modeled as an interpreter with the following in- 
structions. 

• update a local register. 

• provide status information. 

• translate/validate memory requests. 

2.4.1 COMBINING INTERPRETERS 

When composing interpreters, we must show that devices synchronize and share information 
appropriately. The combined system aggregates the functions of the individual components 
and shields the communication between the devices. The interaction between interpreters can 
be made explicit by extending the interpreter model to more fully utilize environments. The 
selection of a transition function in the current interpreter model is dependent on both the 
state and (input) environment; however, an output environment is not present. By defining 
an output environment, it becomes more clear what is being shared and what is private 
state. Devices then communicate through environments where the output environment of 
one device is the input environment of another device. 

The set of state transition functions defining the denotational semantics for each inter- 
preter action is now defined as: 

Jj : Sj x Envi n — ► SjxEnv ou t- 

The next-state function is also more clearly defined as: 

K : SjxEnvin -+ Jj. 
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As an example, consider the interrupt behavior of a system. The top-level system 
interpreter would respond to an environment of external world inputs while manipulating a 
state consisting of the system memory and the set of device registers (CPU, FPU, PIC, 
MMU, DMA, etc.). 

The system implementation may rely on the interrupt function being provided by several 
interacting devices, including a programmable interrupt controller (PIC) and a CPU. The 
CPU input environment would include an interrupt request line, which the PIC will assert 
as part of its output environment when an external request (system environment) is pending. 

The next-state function might be defined as below, where external interrupts (environ- 
ment variables) cause state changes only when interrupts are enabled (state variable). This 
function definition states that when an interrupt is serviced, the program counter (pc) is 
pushed onto a stack and the new pc is assigned a value based on the current state and which 
external interrupt is requesting service. 

The variables intEnabled and pc are part of the CPU state and the variable PIC Reg 
is part of the PIC state. The variable interrupt is part of the CPU’s input environment 
and the PIC’s output environment. 

[interrupt t A intEnabled t) 

— ► PushPC state t 

A pc(t + 1) = IV EC (state t) ( whichlnt(t + 1)) 

A intEnabled(t + 1) = F 
| Executelnstruction(statet) 

A 

interrupt^ + 1) = ( externallntt V internallntt) 

A 

whichlnt(t + 1) = P 1C Priority (P IC Reg t) 


We may also wish to guarantee certain properties about the system, such as if an external 
I/O request is generated in the environment, eventually it will be serviced. This kind of 
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requirement may be part of an abstract model of fault tolerance that the interpreter must 
be shown to satisfy. 

V io t . extIOInt io ( env t) 3t*.t<t* A 

interrupt t f A whichlnt t f = io 
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3.0 PROCESS ALGEBRAS 


Process algebra is the study of concurrent communicating processes in an algebraic 
framework (ref. 21). Processes, in this context, are mathematical objects (like groups) that 
obey a set of axioms. CCS is recognized as having establishing the field. CSP is also a 
well-known example of a process algebra (ref. 22). 

Composed systems are made up of a network of devices with a unity of purpose. The 
behavior of the system is, in some sense, its capability to communicate. From the large body 
of work on concurrency theory, process algebra has emerged as a framework to study the 
interaction of communicating, concurrent processes. While processes are generally thought 
of as executing programs, machines or devices can also be studied under this framework. 
The behavior of each device can be described as a process and the interaction of the devices 
studied as a process algebra. Hennessy defines processes as: “ computational or algorithmic 
entities that when executed, affect and are affected by their environment. The environment 
may be other users, or other computational entities or a combination of both” (ref. 23). 

Processes are expressed as terms in an algebra formed by an equational specification. 
The specification consists of a signature and a set of equations (E,E). The signature is a 
collection of formal function symbols or combinators that define the syntax of terms. The 
equations are axioms that help define the semantics of the objects. A number of other 
definitions are important for discussing the semantics: 

• A E-algebra is an interpretation for the combinators over a set called the carrier. For 
example, given a signature with the combinators {Zero, Succ,Pred, Plus} , a E-algebra 
can be constructed with the carrier being the natural numbers (< N,En >). 

• A term-algebra is an interpretation constructed from the combinators when the carrier 
is the set of terms constructed using the combinators. 

• A E-homomorphism is a function between carriers of E-algebras that preserves the 
structure imposed by viewing them as E-algebras . 

• A E-algebra , I, is initial for a class of E-algebras if for each class member, J, there is 
exactly one E-homomorphism from I to J. 
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• Given a E-algebra and an equational specification (E,E), the E-algebra is said to satisfy 
E if the equations are true for the carrier and interpretation. Or inversely, E holds for 
the E-algebra . The E-algebra is also called a model for E. 


3.1 CALCULUS OF COMMUNICATING SYSTEMS 

This section will briefly describe CCS without probing or examining the semantics involved 
in any detail. The semantic issues will be discussed in section 3.2, which describes process 

algebras in general. 

CCS was designed to model communication and concurrency in complex systems (ref. 3). 
Systems are composed of several parts acting independently of each other, but communi- 
cating with one another to achieve a mutual goal. All elements of the system are modeled 
as agents. The medium used to transmit information between a sender and receiver is also 
modeled as an agent. An agent’s behavior is described by actions , which may be communica- 
tions with other agents or independent concurrent actions. Milner suggests that independent 
actions can also be modeled as (internal) communication. 

The calculus provides five primitives to construct expressions describing agents behav- 
ior: Prefix, Summation, Composition, Restriction and Relabelling. In the pure 
calculus, agents do not transmit data values, but synchronize through indivisible actions 
where a synchronization signal is simultaneously sent by one party and received by an- 
other. The summation ‘operator’ can be applied to duplicate the effect of passing data 
values between agents. By communicating only through pure synchronizations, the calculus 
may ignore value variables. Restriction and relabelling operators have the tightest binding 
followed by prefix, composition, and summation. 

An agent identifies the current state of an entity. Transitions from state to state are 
accomplished by an action. Actions are denoted by labels and describe either synchronization 
or internal transitions. Labels are taken from an infinite set of names. For two components 
to synchronize, they must share the same port name. The notation distinguishes send and 
receive synchronization labels by placing a bar over the name of send labels (e.g., c). Internal 
transitions are labeled by the reserved label r, which has no complement. 

For example, in the figure below, agent A has an input synchronization port (in) and, 
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an output synchronization port (out). 



The behavior of the agent might be defined as follows: 

A =itj p A' 

A' — ief V.A 

These agents describe a semaphore and show the use of the Prefix ( u .” ) operator. 
Agent A waits to synchronize with some other agent and, upon completion, behaves as A! . 

Composition hooks together two independent agents and is denoted with a vertical 
bar. For example, consider the following agents: 

A — it} O-A 1 
A' —it} c.A 


B =itj c.B' 

B‘ = dt j b.B 

The composite agent ( A \ B) may be connected as follows: 



We can also write A =i e) a. A' as A A A'. The transitional semantics of the language 
(described below) allow us to infer the following: 

a. From A A A', we infer A | B A A' | B. 
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b. From A' A, we infer A' | £ A | B (this represents communication between A' 
and some agent other than B). 

c. Since A' A A and B A B' we can infer A' | £ A A | £' (internal transitions). 

d. From £' £, we infer A | £' X A | £. 

By imposing Restriction on the composition of A and £ (i.e., A | £\c), the action c is no 
longer externally available. This implies item (2) would then be excluded. 

In the above examples, each agent was defined as conducting only one action. The 
Summation operator (+) is used to define agents that may make one of several (possibly 
infinite) transitions. For example, an agent similar to A could be defined to either accept 
input signals or send output signals as follows: 


C =dej “I" 

Relabelling allows agent definitions to be reused. Using relabelling we could use the 
same agent definition for A and B above. Given a relabelling function /, A[f] denotes a 
copy of agent A with appropriately modified action names. 


3.1.1 TRANSITIONAL SEMANTICS 

CCS provides several rules describing the semantics of the expression constructors: 

Act 

a.£ A E 


Sumj 


Ej ± g 

£,</ Ei A E'j 


U € I) 


Comi 


E 

E | F A E' | F 
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Corri 2 


F' 

E | F A E | F' 


Com3 


Res 


Rel 


Con 


E^E'andF^F' 
E\ F ^ E'\F' 


£A£' 
E\L ^ E'\L 


(a, a £ L) 


E[f] E'[f) 


P±_P_ (A 

A P' iei 


3.2 SEMANTICS 

Our primary concern regarding semantics pertains to the meaning of agent equivalence. 
Certainly different E-algebras will identify different machines and the sequence of actions 
a machine may perform. We want the equation axioms to restrict the set of models that 
satisfy the equational specification to those models that are real processes (devices). 

As processes are inherently non-deterministic, the behavior of a process could be char- 
acterized by a set of action sequences (traces). One of the properties of a CCS term is to 
abbreviate this set. CCS terms also have an important dynamic aspect. Communication 
links and capabilities as well as the number of components, can all change as the system 
evolves. 

For example, the agent a. (6+ c) can produce the trace set { (a, A), (a,c) }. Likewise, 
the agent a.b + a. c produces the same trace 1 . The question then arises, are these agents the 
equivalent? 

*For purposes of reducing syntax, we will frequently write a.b as simply ab. 
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a(b + c) = ab + ac 


( 1 ) 


Using a trace semantic definition of equivalence, the two agents are equal. However, 
this equivalence does not hold for all process algebras. 

Of the five combinators, the summation function is the most open to different semantic 
interpretations: the restrict and relabel operators are clearly more of a convenience than 
a necessity; the composition operator can be defined in terms of the summation operator 
(see section 4.2 ); and the primitive nature of the prefix combinator provides little freedom 
for varying its meaning. To define the meaning of the composition operator, however, the 
timing of choices a system makes must be carefully considered. The agents in equation ( 1 ) 
illustrate this idea. 



Figure 3.2-1: Example of Process Algebra Semantic Interpretations 


The agent ab -f ac represents an agent that makes a choice to behave as the agent ab 
or the agent ac. If a specification equation were to declare that the prefix operator left- 
distributes over the summation operator, then the two agents would be equivalent. When 
this left-distribution axiom is not present, the agent a(fc+c) postpones the choice of a second 
action until after the action a occurs. Depending on when the choice between two traces 
is made, the behavior of two agents of can be quite different as viewed from an observer 
agent. In Figure 3.2-1 this difference in the moment of choice is exhibited by the difference 
in branching structure. 

Adding the axiom prefix left-distributes over summation would allow many unrealistic 
process models to satisfy the equational specification, so it will not be present in the set of 
equations. 
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The notion of equivalence we will use is that of bisimulation (ref. 3). Two agents are 
equivalent by bisimulation, if an outside observer cannot distinguish between them. More 
formally, P = bisimulate Q • 

a. If P A P' then for some Q\ Q A Q' and P' —b, simulate Q' • 

b. If Q Q' then for some P', P —* P' and P' —b, simulate Q'- 

Proofs of equivalence are done by constructing bisimulations. However, state explosion 
can quickly occur, making these proofs difficult. The solution is to use equations! reasoning. 
This requires a relation where equivalence is a congruence (reflexive, symmetric, and tran- 
sitive). Congruence on CCS agents is an equivalence relation satisfying the following set of 
properties: 

if i4 ~~~cquiv ^ and P “~eguiv P then 


a. A -{- P — eguiv P I 

b. A\P =equiv B \A 

C. fl.A — eguiv 

d. A\l = equiv A'\l 

e. A[f] = equiv A’[f\ 

{. A = E[A } A B = F[B ] A VP E[P] = F[P] =► A = equiv B 

The basic axioms of CCS are presented in Figure 3.2-2. Most variations of CCS in- 
corporate these laws and differ in what equational laws regarding the internal action are 
included. A brief summary of six such process algebra variations is presented in (ref. 24). 

3.2.1 INTERNAL ACTIONS 

The internal action r, also requires special attention to define when an agent chooses to take 
an internal action. As the semantics of r vary, so does the meaning of equivalence relation 
and, thus, what interpretation models satisfy the process algebra defined. The basic issue is 
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Figure 3.2-2: Basic Axioms of CCS 


summation (monoid) laws 

composition laws 

P + Q = Q + P 

P\Q = Q\P 

P + (Q + R) = (P + Q) + R 

P\(Q\R) = (P\Q)\R 

P + P = P 

P + 0= P 

P\0= P 

restriction laws 

relabelling laws 

(o.Q)\L = 

(«.Q)[/1 = /(«)•<?[/] 

(Q + R)\L = Q\L + R\L 

(0 + R)[f) = Q[f) + R[f) 

o 

II 

o 

o [/] = o 

The Expansion Law 

a.P | (3.Q = o{P | P-Q) + 0( a -P 1 0) + 1 

' r(P\Q) */(<* = ?) 
0 otherwise 

< 


how observable are internal actions to an outside observer. For example, we must consider 
whether the agent a.P + r.b.Q is equivalent to the agent a.P + b.Q (Figure 3.2-3 displays 
the branching structure of these agents). 

A strict interpretation of these agents (using strong equivalence) would suggest the 
agents are not equivalent. The agent a.P + b.Q is able to communicate with its environment 
through actions a or b. The agent a.P + r.b.Q, however, will either 1) only communicate 
through action a , or 2) only communicate through action b. Which behavior is observed 
depends on whether or not the internal action is taken. 

A hierarchy of equivalences is presented in the Figure 3.2-4. The weakest equivalence is 
the trace equivalence definition where two processes are equal if the set of all possible traces 
that the two may execute is the same. Strong equivalence requires strict equality in what 

internal actions do. 
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a.P +r.b.Q 


a.P +b.Q 



Figure 3.2-3: Internal Action Decision Point 

The arrows in Figure 3.2-4 are meant to indicate that if two processes are strongly 
equivalent, then they are observationally congruent, Likewise, if two processes are observa- 
tionally congruent, then they are observationally equivalent. Observational equivalence is a 
weaker form of bisimulation. Observational equivalence equates the agents t.B and B while 
observational congruence makes a distinction between them. The r laws for observational 
congruence that we will use are: 


a. Ct.T.P — equtv a.P 

b. P At. P = equ iv t-P 

c. a(P + r.Q) + a.Q — equtv a (P + t.Q) 
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Strong Equivalence 
(bisimulation) 

Y 

Observational Congruence 

Observational Equivalence 
(weak bisimulation) 

V 

Trace Semantics 

Figure 3.2-4: Process Algebra Equivalence Relations 
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4.0 MECHANIZATION OF THE PROCESS ALGEBRA 


This section will describe preliminary work to represent CCS in HOL. There has been 
significant recent interest in mechanizing process algebras in HOL (refs. 25, 26 and 27). 
The development described here takes a purely definitional approach. This representation 
has allowed us to directly prove several of the CCS semantic laws. We are also interested 
in a vehicle to investigate modifications to the CCS logic to handle data passing as well as 
synchronization. 

To develop the process algebra in the HOL logic, we take advantage of several type 
definition mechanisms provided by the logic. Using these facilities we define an initial al- 
gebra (ref. 28) for agents , which are constructed from sequences of actions. The purpose 
of types in higher-order logic is to prevent the inconsistency that higher-order variables can 
induce. The recursive type definition facility (ref. 29) automates the process of defining 
new data types in terms of already existing types. Both constants of the new type and type 
operators can be defined. Type operators are constructor functions, used to build compound 
members of new type from the type constants. The properties of these new types are then 
derived by formal proof. This guarantees that the new type does not introduce inconsistency 
into the logic. Additional recursive operators can be defined to operate on the concrete data 
representation of the type. 

As shown in Figure 4.0-5 from Melham’s paper (ref. 29), the new type is defined by 
adding an axiom to the logic that asserts that the new type is isomorphic to an appropriate 
subset of an existing type. The predicate P : ty — ► bool defines some useful subset of the 
type ty. 



ty 


Figure 4-0-5: New Type Isomorphism 
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4.1 ACTIONS 


Using the recursive type definition facility, actions are defined to be either internal or external 
transitions. The internal action represents the r action of CCS. External transitions require 
a label, which consists of a name (string) and boolean value, that denotes whether the action 
is a send or receive synchronization operation. 

new_type_abbrev('name‘ , string") ; ; 
new_type_abbrev( ' label ' , " iboolt^name") ; ; 

let ACTION ■ define .type 'action' 

'action * INTERNAL I EXTERNAL label';; 


Several auxiliary recursive function definitions are defined for the action data type. An 
induction theorem for the type is provided and a simple theorem is proved showing that all 
actions must be either internal or external and not both. 


h de i (Is. Internal. Act IITERIAL * T) 
hj e r (Is Extern al.Act IITERIAL - F) 
h def V 1. LBL(EXTERIAL 1) = SID 1 
h de j V 1. TYP(EXTERIAL 1) = FST 1 


A (VI. Is_Internal_Act(EXTERIAL 1) * F) 
A (VI. Is_Erteraal_Act(EXTERIAL 1) = T) 


ACTIOIJIDUCT * 

h V P. P IITERIAL 


A (V p. P(EXTERIAL p)) =* (V a. P a) 


action.c&ses * 

I- V a. (Is.Extarnal.Act a 
-i (Is.Extarnal.Act a 


I s .Internal. Act a) A 
Ia.Internal.Act a) 


IS.COMPL.ACT = 
h V a b. IS.COMPL.ACT a b 


(LBL a = LBL b) A (TYP a = -• TYP b) 


4.2 AGENTS 

The type representation covers the syntax of the concrete data type. Note that a term 
algebra is also formed. It would seem good practice for the representation definition of any 
type to minimize the number of type operators. This is certainly true if the semantics of 
some operators can be defined in terms of others. 

For determining the equivalence of two agents, we would like to define all agents in a 
normal form with agent terms consisting of only the prefix and summation operators. 
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To describe processes that execute in parallel, we adapt a method described in (ref. 21). 
This technique allows composed, concurrently executing agent expressions to be converted 
to an equivalent agent expressed only with the prefix and summation operators. We define 
three mutually recursive functions to replace the composition type constructor: 

a. A communication operator, COMM, which declares that two agents will communicate 
if they have complementary, enabled actions. 

b. A left-merge operator, LMERGE, which creates a new agent from two agents, such 
that the new agent must first behave as though only the left agent (first argument) 
were present and followed by an agent constructed by the composition of the resulting 
left agent and original right agent. 

c. A compose (“merge” in the literature), COMPOSE, which creates an arbitrary inter- 
leaving of the two agents (through use of the summation type constructor). 

The functions relate through the following laws. We will use the symbol “||”, for the 
COMPOSE operator, the symbol “|” for the COMM operator and “T” for the left-merge 
operation. 

a. Given P = a.P'andQ = b.Q' 

P \Q = (a = COMPLEMENT b) -4 r.(P' || Q') else 0 

b. 1 || y = ( xLy ) + ( yLx ) -I- (x | y) 

c. aLx = a.x 

d. a.xLy = a.(x || y ) 

e. (1 + y)Lz = ( xLz ) + ( yLz ) 

f. ax | bx — (a | 6).(x || y) 

g. (1 + y) | z = (x | z) + (y | z) 

h. x | (y + z) = (z | y) + (x | z) 

The functions COMPOSE and LMERGE, are mutually recursive. Regrettably, HOL 
does not provide a mechanism for defining mutually recursive functions. To handle this prob- 
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lem, we include two auxiliary compound type operators in the type definition and axiomatize 
their semantic meaning (see the HOL code below). 

Using the CCS restrict operator, a CCS agent can be constrained so that (a set of) 
specified actions cannot form links with other agents. The restrict operator in our grammer 
restricts an agent for a single action. This does not result in a significant loss of function; 
for example, the agent: 

(a. A + b.B)\{a,c } 


can be defined by: 


{(a.A + b.B)\a)\c 


let AGEHT = deline.type 'agent' 

‘agent = IIACTIVE 

I PREFIX action agent 
I SUMM agent agent 
I COMPOSE agent agent 
I LMERGE agent agent 
I RESTRICT label agent’ ;; 


let AGEIT.IIDUCT = »av«_thm(‘AGEIT_IIDUCT' , prove_induction_tlue AGEVT) ; ; 
let AGE!T_CASES * proee_caeee_th« AGEIT.IIDUCT ; ; _ Tl . . 

let AGEIT_COMSTRUCTORS_DISTIliCT * prova_constructors_di*tinct(AGElT; , . 
let AGEIT_one_one = prove_con»tructore_one_one AGE1T; ; 


COMM_DEF_AX = 
h V A B a b. 

COMM (PREFIX a A) (PREFIX b B) * 

IS COMPL.ACT a b — > PREFIX IITERHAL 


(COMPOSE A B) 


IIACTIVE 


COMM_DIST_AX = 

H V A B C. (COMM (SUMM A B) C 
(COMM A (SUMM B C) 


SUMM (COMM A C) (COMM B C)) A 
SUMM (COMM A B) (COMM A C)) 


COMPOSE AX s 

(- y i COMPOSE A B = SUMM (SUMM (LMERGE A B) (LMERGE BA)) (COMM A 


B) 


LMERGE.AX = h V A B a. LMERGE (PREFIX a A) B « PREFIX a (COMPOSE A B) 


LMERGE.DIST.AX = 
h V A B C. LMERGE (SUMM A B) C 


SUMM (LMERGE A C) (LMERGE B C) 


While HOL allows the embedding of other logics, the native HOL syntax must be used. 
This makes CCS terms stated in HOL difficult to understand and awkward to use (as the 
above theorems show). For example, even the fairly simpleagent expression: (a.E+l.0)\(a.F) 
will be output as (and must be input as): 
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(COMPOSE (SUMM (PREFIX (EXTERN AL(T, ’a’)) E) (PREFIX) 
(COMPOSE (SUMM (PREFIX (EXTERNAL(T,V)) E) 

(PREFIX (EXTERN AL(F,’b’)) INACTIVE) ) 
(PREFIX (EXTERN AL(F, ’a’)) F) ) 


To reduce the difficulty in manipulating embedded languages, new library facilities are 
available in HOL88 Version 2.0. The new library facilities include a “pretty printing” library 
and a “pretty parser” library for the HOL theorem-proving system. The use of these tools 
will be described below in sections 4.4 and 4.5. 


4.3 TRANSITION SEMANTICS 

Having defined the form of agents in the previous section, we define a relation between 
two agents that captures the semantic definition of labeled transitions (e.g., A — » B ) This 
relation can be defined using the inductive relation definition package. 

The inductive relation definition package provides a set of theorem-proving tools based 
on a newly derived principle of definition in HOL for defining relations inductively by a set of 
rules (ref. 30). Rules consist of a list of premisses and side conditions and a conclusion. Each 
premiss must make a positive assertion about membership in the relation. Side conditions 
may be arbitrary propositions not involving the relation being defined (as an example, see the 
TRANS-RES law definition below). The rules are essentially implications: if the premisses 
and side conditions hold, then the conclusions hold. The relation is inductively defined by a 
collection of such rules to be the least relation closed under all the rules. 

The TRANS function defined below states that for an agent to evolve to another agent, 
there must be an immediate transition by a prefixed action or a set of premisses must be 
satisfied. To embody all the laws described in 3.1, symmetric forms are needed for summation 
laws and the composition laws. 
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let (TRAMS.rules, TRAMS.ind) = _ , M . 

l«t TRAMS = "TRAMS :agent->action->agent->bool in 
n«H_ induct ive.def init ion false 'TRAMS' 

("‘TRAMS x a y",D> 

[ 

y. ACT LAW y. 

[3. V 

% 

"‘TRAMS (PREFIX ay) ay" 

■J, SUM1 LAW % 

[ "‘TRAMS x a y” 3 , 

% 

••‘TRAMS (SUMN x z) a y M 

; y. sum 2 law y. 

[ "‘TRAMS x a y" ], 

y % 

"‘TRAMS (SUMN z x) a y" 

;*/. CONI LAW % 

[ "‘TRAMS x a y" ] , 

y t 

"‘TRAMS (COMPOSE x z) a (COMPOSE y z)" 

;•/. COM2 LAW V. 

[ "‘TRAMS x a y" 3 , 

y m y* 

"‘TRAMS (COMPOSE z x) a (COMPOSE z y)" 

: y. COM3 law y. 

[ "‘TRAMS x (EXTERMAL (T,s)) x ,M ; 

••‘TRAMS y (EXTERMAL (F,s)) y ,n 3. 



"‘TRAMS (COMPOSE x y) IMTERMAL (COMPOSE x* y’) M 
;*/. RES LAW X 

[ —TRAMS x a y"; „ 

”*( (LBL a) = (SMD (r:label)))" 3, 



"‘TRAMS (RESTRICT r x) a (RESTRICT r y) 


let TRAMS, 
let TRAMS, 
let TRAMS, 
let TRAMS, 
let TRAMS, 
let TRAMS, 
let TRAMS. 


(el 1 
(el 2 
(el 3 
(el 4 
(el S 
(el 6 
(el 7 


TRAMS. 

TRAMS. 

TRAMS. 

TRAMS. 

TRAMS 

TRAMS 

TRAMS 


.rules) 

.rules) 

.rules) 

.rules) 

.rules) 

.rules) 

.rules) 


let TRAMS.IMDUCT.TAC = RULE.IMDUCT.THEM TRAMS. ind ASSUME.TAC ASSUME.TAC;; 
let TRAMS.CASES * derive_cases_tha>(TRAMS_rules .TRAMS.ind) ; ; 

let TRAMS.ACT.EXISTS = neH_definition('TRAMS ACT EXISTS', 0*V)- 

m ip Q TRASS. ACT. EXISTS P Q = ?P* Q* a. (TRASS P a P’) /\ (TRASS Q a Q ) 


Using the definition of TRANS, we can prove that agents can evolve to other agents 
(e.g., liveness properties). The relation FBY, describes the transitive closure of the TRANS 

relation. 
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let (FBY.rulea, FBY.ind) = 

let FBY = "FBY:agent->ag«nt->bool" in 
n«w_inductive_def inition lalee 'FBY 1 
("“FBY A B", []) 


"“FBY A A" 


[ "TRAHS A a C"; 

"“FBY C B" 

*/.2 y . ] . 

"•FBY A B" ];; 

let FBY.REFL * (el 1 FBY.ruleo);; 

let FBY.TRAIS = (el 2 FBY.rules);; 


4.4 PRETTY PRINTING SUPPORT 

A set of rules can be defined so that the CCS terms are presented in a form resembling their 
form in the literature. Each rule consists of two parts, which are separated by the operator 
->: a pattern and a format. Each pattern defines a context in which the rule is relevant and 
a template that a HOL term much match for the rule to be fired. The template may also 
contain optioned type information. The format defines horizontal spacing parameters (e.g., 
where line breaks should appear) and how the HOL term should be printed. Frequently, this 
information informs the pretty printer that a new context should be entered. For example, 
the following rule will cause the pretty printer to to print the string tau for the internal 
action constant INTERNAL. 

'term' : : CONST (INTERNAL () ,**) -> [<h 0> "tau”]; 

To activate a pretty printer specification, the follow HOL code must be executed. This 
code redefines the HOL system print function (top_print) to first attempt to print terms us- 
ing the ccs_rules and if they fail, to use the built-in rules. The variable assignable.print.term 
must be reassigned so that the subgoals package also prints using the new rules. 


top_print (\t. pp (ccs_rul«»_iun then_try 

hol_t«rm_rulea_iun than_try 

hol_type_rul*3_fun) 'term' □ (pp_convert_t«ra t)) ; ; 

lat ccs_t«rm_print t = 

pp (ccs_rtile#_iun then.try 

hol_term_rul«s_lim then_try 

hol_type_rules_fun) 'term' [] (pp_convert_term t) ; ; 
assignabl*_print_t«rni := ccs_t«rm_print ; ; 
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: :COMB(COMB(COIST(#‘#() ,**) ,*ch) ,COHST(#‘#() .♦*)) 

-> L<h 0> *ch ] ; 

: : VAR(*»tr,**) -> C<h 0> "<“ *str ">"] ; 

: :COIST(**tr,**) -> [<b 0> *»tr] ; 

: : COMB (COMB (COIST(STRIXG() ,«■*) ,*ch) ,*str) 

-> [<h 0 > *ch 'Ibis* : :*»tr] ; 

:COMB(COMB(CO«ST(#,#() ,**) ,COIST(F() ,**)) ,**tr) 

-> [<h 0 > ’lbli* : :*»tr] ; 

: COMB(COMB(COIST(# ,#() , **) . CO*ST(T( ) ,*♦)). **tr) 

-> [<h 0> ’lbl«' : :*str] ; 

: :COHST(IITERIAL() ,♦♦) -> C<h 0> "tau"]; 

: :COIST(IIACTIVE() ,**) -> [<b 0 > " 0 “] ; 

: :COMB(COIST(EXTERIAL() ,**) ,*label) -> C<h 0 > *lbl* : :*lab«l] ; 

: :COMB(COMB(COIST(PREFIX() ,**) ,*act) ,*ag) -> l<h 0 > *act . *agj ; 


» : ;COMB(COMB(COIST(COMPOSE() ,**) ,*agl) ,*ag2) 

-> [<h 0> "(" *agl M Tl “ *a*2 ”)" 3; 

- : : COMB ( COMB (COIST(LMERGE() ,**) ,*agl) ,*ag2) 

-> [<b 0> M (" *agl M L " *ag2 ") M 3; 

* : : COMB ( COMB ( VAR ( COMM () ,**) ,*agl) ,*ag2) 

-> [<h 0> "(” *agl "I" *ag2 ")" 3; 

* : :COMB(COMB(COIST(SUMM (),**) ,*agl) .*ag2) -> C<b 0> ♦agl " + "**«23; 

* ::COMB(COMB(CO«ST(RESTRICT(),**).*l»*t),*ag) -> [<h 0> *ag \ ; 

> : : COMB ( COMB (CO*ST( RELABEL () ,**) ,*ag) 

-> [<b 0> *ag " C" *rfun "3 " 3 ; 

» : :COMB(COMB(COMB(COXST(TRAXS() ,**) ,*agl) ,*act) ,*ag2) 

-> [<h 0> *agl " -<" *act M *ag2 3 ; 


Figure 4-4-1: Pretty Printer Rule Specification 


4.5 PRETTY PARSING SUPPORT 

A generic parser-generator is provided as a library in HOL88 Version 2.0. The input to 
the generator is a form of modified BNF notation consisting of terminals, non-terminals, 
and action symbols. The parser-generator can only accept a syntax for a non left-recursive 
context-free grammer. Action symbols are embedded in the grammer to construct the in- 
tended semantics for the syntax. 

For pretty parsing to work, a set of ML functions are defined, which are activated when 
the parser completes a grammer rule. These rules convert CCS terms into HOL terms. 
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Figure 4-5-1: Pretty Parser Grammer Specification 


FIRST.CHARS ‘abcdefghij klmnopqratuvwxyz 
ABCDEFGHI JKLHIOPQRSTUVHYZ 

* * . 

CHARS 'abcdilgbijklinopqrstuvvxyz 
ABCDEFGHIJKLMNOPQRSTUVWXYZ 
1234607890*'. 

USEFUL [("*, ***)]. 

MAII.LOOP — > term [EOF] . 

term — > agent more. agent. 

more.agent — > agent. op more.agent I [] . 

agent — > [(] agent more.agent [)] 

I [0] {mk.const ( * INACTIVE * , agent")} 

I action prefix 
I {mk.var (TOKEN , M : agent” )} . 

action — > [T] < mk.const ( * UTERI AL 1 , " : act ion" ) } 

I inlabel { mk_cca_action( POP) > 

j [-] outlabel i mk_ccs.action( POP) } 

I {mk.var (TOKEN,": action 14 )>. 

prefix — > [.] {mk_ccs_act_comb( * PREFIX * , POP , agent)}. 

agent.op — > [+] {mk_ccs_comb( ‘SUMM* ,P0P, agent)} 

I [|] {mk_ccs_comb( ‘COMPOSE* , POP, agent)} 

I [=] action [=] [>] {mk.ccs.trans (POP, POP, agent)}. 

inlabel --> [0 { mk_ccs_label( M T:bool" , WORD) } [0. 

outlabel — > [*] { mk_ccs.label("F:bool" , WORD) } ['] . 

inactive — > [0] {mk.const ( ‘ INACTIVE* , "ragent")}. 


let mk.ccs.act_ comb (op, a, b) = mk_comb(mk_comb( 

mk.const (op," : act ion->agent->agent") ,a) , b) ; ; 

let mk.cca.comb (op, a, b) = mk_comb(mk_comb( 

mk_const(op, M :agent->agent->agent") ,a) , b) ; ; 

let mk_cc8_label( b, w )= mk.pair( b, mk.const ( ‘V* *\“ ,": string") );; 

let mk.ccs.action( 1 ) = mk_comb( mk.const( ‘EXTERNAL* , " :label->action") ,1) ; ; 

let mk.ccs.trans (A, act, B) = mk_comb(mk_comb(mk_comb( 

mk.const ( * TRANS * , " : agent->act ion->agent->bool" ) 

, A) , act) , B) ; ; 

let SEPS = [(*(*, □);(•)*,□); ( ‘ ‘ D); 

(‘+‘,n);('T',n)];; 

let parse thing = (P ARSE.text (thing, □, SEPS)) ; ; 

new_ayntax.block( *«* , *» * , ‘parse * ) ; ; 
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When the HOL term parser finds a new syntax block (as defined above), the parser 
constructed is given the complete string within the syntax block (delimited by « and »). 
The parser is expected to return the corresponding HOL term. 

The following example demonstrates such a proof and show the use of the pretty parser 
and pretty printer. 


let X - '(’a’.E + -’b’.O) I (-’a* .F) * ; ; 

let Y = '(E I F)';; 

let T = (X* * =T=>‘ * Y) ; ; 

let Z = (PARSE_text( T.CJ.SEPS));; 

X = *(’a’.E + -’b’.O) I (-’a’.F)' : string 
y = ‘(E I F) ' : string 

T = *(’a’.E + -’b’.O) I (-’a* .F)=T=>(E I F)' : string 
Z = ”(‘a , .E+- , b‘.0 II -'a' .F) -<tau>~> (E 1 1 F) H : tern 

set .goal ( [] ,"‘Z") ; ; 

M (‘a‘ .E+-‘b' .0 II -’a'.F) -<tau> — > (E II F)" 

() : void 
Run time: 0.3s 

e( RULE.TAC TRAIS.C0M3 

THEM EXISTS.TAC "‘a*" 

THE! COIJ.TAC 

THEIL [ RULE.TAC TRAIS.SUM1 THEM RULE.TAC TRAIS.ACT 
; RULE.TAC TRAIS.ACT ] ) ; ; 


OK. . 

goal proved 


I- TRAIS 
C COMPOSE 

(SUMK(PREFIX(EXTERIAL(T, ‘a’ ))E) (PREFIX (EXTERIAL(F, ‘b* ) )IIACTIVE) ) 
(PREFIX (EXTERIAL(F, ‘a*))F)) 

UTERI AL 
(COMPOSE E F) 


Run time: 0.1s 

Intermediate theorems generated: 42 


pp.thm (top.thmO );; 

M (*a‘ .E+-‘b‘ .0 II -‘a‘.F) -<tau>--> (E II F)*’ : term 
Run time: 0.0s 
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4.6 AGENT EQUIVALENCE 


As described in section 3.0, several notions of equivalence between agents can be defined. 
The kinds of models that the initial algebra satisfies will be determined by which notion of 
equivalence is used. Trace semantics can be shown by defining the meaning of an agent as a 
set of traces where a trace is a list of actions. 


new_type_abbr ev ( * trace 

, M : action list") ; ; 


new_type_abbrev (‘traces 1 , " : trace set M );; 


let TR = new^recursive. 

.definition false AGEIT 'TR' 


"(TR(IIACTIVE) 

= {}: traces) /\ 


(TR(PREFIX a A) 

= { t I (HD t > a) A (TL t IH 

(TR A)) > ) A 

(TRCSUMH A B) 

= { t I (t I» TR(A) ) V (t II 

(TR B)) } ) 


Trace semantics permit fairly broad equivalence classes to be constructed. We are 
frequently interested in a narrower definition of equivalence where two agents are equivalent 
if an external agent cannot distinguish between the visible behavior (traces) of the two 
agents. When using the notion of strong equivalence, traces consist of both external and 
internal actions. For our application, a weaker notion of observation equivalence where 
internal actions cannot be detected by the external agent, is sufficient. 

We are actually interested in a weaker form: one-way observation equivalence. Under 
this definition, P implements Q’s behavior if for every action a of Q, every a-derivative of 
Q is one-way observation equivalent to some a-descendant of P. 

For the remainder of the paper we will use the term observation equivalence to mean 
one-way observation equivalence. 

Observation equivalence can be defined in terms of an inductive relation definition. 
Observation equivalence laws are defined for compound terms, which are constructed using 
only the PREFIX or SUMM operators. 
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Rules 1 and 2 are straightforward; observation equivalence is reflexive and two agents 
prefixed with the same action are observation equivalent if the agents without the prefixed 
action are observation equivalent. 

If the left-hand-side agent is a summation of two agents (i.e. OE (SUMM A B) C ) 
rules 3-5 may apply, and one-way observation equivalence is achieved if either: 
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a. Both of the summation agents (A and B) satisfy observation equivalence with the 
right-hand-side agent (C). This is rule number 5, OE.LSUM. 

b. The left summation agent (A) satisfies observation equivalence with the right-hand-side 
agent (C) and there is no action for which a transition for both the right summation 
agent (B) and the right-hand-side agent (C) exists. This is rule number 3, OE.LSUML. 

c. The right summation agent (B) satisfies observation equivalence with the right-hand- 
side agent (C) and there is no action for which a transition for both the left summation 
agent (A) and the right-hand-side agent (C) exists. This is rule number 4, OE.LSUMR. 

The last rule states that if the right-hand-side agent is a summation agent, then the 
left-hand-side agent must satisfy observation equivalence for both of the right-hand-side 
summation agents. This is the symmetric case of rule number 5 for a left-hand summation. 

Note that symmetric rules for rules 3 and 4 do not exist. If they were present, the OE 
relation would specify trace semantics. For example, 

OE (a.O + b.O) (b.O + a.O) 

requires both: 

OE (a.O + b.O) (a.O) 

OE (a.O + b.O) (b.O) 

Adding the symmetric rules would allow relations such as 
OE (b.O) (a.O + b.O) 

to be true. If the semantic meaning of the OE relation is read as “implements”, then 
(a.O + b.O) implements (a.0) 

but (a.O) does not satisfy /implement (a.O + b.O) 

4.6.1 EQUIVALENCE PROOFS 

Based on the above definitions of actions, agents, transitions, and equivalence, many of the 
CCS axioms can be proved. For example, in the box below, we show the proof script for 
the summation law: P + 0 = P 
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l«t SOM IMACTIVE = prov*_thm(‘SUM_IHACTIVE‘ , 

" " • P : agent . OE (SUMM P IMACTIVE) P". 

GE*_TAC 

THEM EULE.TAC OE_LSUML 

THEVL [ REWRITE.TAC [TRAMS. ACT.EXISTS] 

THEM COMV.TAC IOT_EXISTS_COIV THEM GEI.TAC 
THEM COMV.TAC IOT_EXISTS_COIV THEM GEM.TAC 
THEM COMV TAC MOT_EXISTS_COMV 
THEM REWRITE.TAC [DE_MORGAM_THM] 

THEM GEM.TAC 

THEM MP S TAC T ( C SPECL ["IMACTIVE" ;”a: action"; "P’"3 TRAMS.CASES ) 
THEM REHRITE.TAC [AGEMT_COM STRUCTORS_D I STI MCT ] 

RULE.TAC OE.REF 

] );; 


4.7 EXTENSIONS 

For our purposes, neither the recursive operator nor the relabel operator have been necessary. 
However, work is currently underway to add a repeat operator to the type definition. This 
operator is available in the * r calculus developed by Melham (ref. 27). The relabel operator 
would be easy to add if warranted by further application of the calculus. 
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5.0 MECHANIZATION OF DEVICE INTERACTIONS 


5.1 GENERIC INTERACTIONS 

In this section, we will show how the process algebra formalism developed in section 4.0 
can be used to specify various types of device interactions. Device communication may 
require only a single message or a series of messages to be passed between two devices. At 
a lower level, the information is passed over a bus using a hardware protocol (e.g., 4-phase 
handshaking). 

The types of interactions can be loosely described as belonging to one of the following 
categories: 

a. Remote Procedure Call, 

b. Message Passing, 

c. Process Creation (fork), and 

d. Rendezvous. 

These forms of interaction are described in concurrent programming literature. While 
the Ada programming language provides primitive support for only remote-procedure-call 
and rendezvous features, the SR programming language provides primitive statements for 
each of the above interaction forms. 

5.1.1 REMOTE PROCEDURE CALL 

A CPU and a memory subsystem interact in a remote-procedure-call manner. The CPU 
sends a memory request to the subsystem and waits for a response. If the memory subsystem 
includes a memory management unit (MMU), the MMU and the actual memory may also 
interact in a remote procedure form. 

In the example below, we show a proof of a 4-phase handshaking protocol between a 
CPU and a bus. This example is somewhat simplified as the bus returns a data value rather 
than actually reading a memory location. 
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lmt cpuRaissRsad * * -'cpu.addr;.- cpu_ 
let cpuRaadHem = * ■ ’data! vail’ • 'data ( *' 

let cpuSropRead = ’ • -’ cpu.addr cpu.rRsq ;; 

let cpuReadComplete * 1 . SUCCESS 1 ; ; 

let bueGetRead * * ‘cpu.addr* . |cpu_rReq* 

let bueReturnMea = * • -’data! vail’ .-’data >> 

let bueDropRead * ' • * cpu.addr ’ . ’ cpu.rReq ; ; 

let bueReadConplete * 1 . SUCCESS * ; ; 


let cpuRead = cpuRaieeRead*cpuReadMea*cpuDropRead*cpuReadCoiiplete; ; 
let busRead = bu»GetRead‘bu»Returnl!ea‘buBDropRead-bu8ReadComplete; ; 


let syst«m_daf = * ( * “cpuRead" ‘ ) I ( 1 'busRead" ‘ ; 
let system = Agent system.dsl ; ; 

let systea.done = 1 SUCCESS I SUCCESS * ; ; 
let success = Agent system.done; ; 


5.1.2 MESSAGE PASSING 


Devices also interact through a message- passing format. For example, consider the inter- 
action between a CPU and an interrupt controller. These devices operate simultaneously, 
performing independent tasks, and may never interact (this is, of course, unlikely). If an 
enabled I /0 device generates an interrupt, the system’s interrupt controller will send a mes- 
sage to the CPU indicating that some device requires attention. At this point the CPU 
may or may not respond. Depending on the signaling discipline (e.g., signal-and-conttnue or 
signal- and- wait ), the interrupt controller may also continue to operate. 

Another example of the message passing form is the instruction-buffer management 
interaction between an 8088 CPU and its floating-point-instruction coprocessor (FPC), the 
8087 (ref. 31). The CPU and FPC both maintain an instruction prefetch buffer. Instead 
of both devices duplicating all the instruction decode logic, the CPU sends messages to the 
FPC indicating how each byte should be interpreted (e.g., remove first byte, interpret byte 
as FPC instruction, flush the buffer, no change). 

The example below shows how the interaction between a CPU and a PIC can be 
modeled. 
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let cpulnt = * ’int Pending’ .CPU_PROCESS_IIT‘ ; ; 

let cpuIntEnabled = cpulnt* *♦ tau . FETCH.IISTRUCTIOI ' ; ; 
let cpuIntDisabled = ' FETCH. IHSTRUCTIOH ‘ ; ; 

let piclnt * * -’intPending* .PIC.PROCESS.IIT 

let picReq * piclnt* * + tau.PIC.CHECK ‘ 

let picHoReq = * PIC.CHECK 

let system.d el = ' ( ' *pic* * ) I (“cpu* ') * ; ; 


5.1.3 PROCESS CREATION AND RENDEZVOUS 


The interaction between a CPU and a Direct Memory Access device (DMA), can be char- 
acterized as process creation followed by a rendezvous. A DMA must be programmed to 
supervise the transfer of data from an I/O device to memory. The process of initializing 
and activating the DMA is a form of process creation. When the DMA has completed 
its task, the CPU (probably through the interrupt controller) will be signaled. In many 
circumstances, the CPU activity must rendezvous with the completion of the DMA activ- 
ity. For example, when a new code page must be brought into memory for an executing 
program to continue, the CPU may switch to other executing programs, but once all other 
programs have completed, the CPU (really the OS kernel) must wait for the DMA activity 
to complete. 


let dmaProcCreate 

= 

* cpuVriteRag.cpuInitExec.DHA.EXEC* ; ; 

let dmaSleep 

= 

dmaProcCreate; ; 

let dm&Done 

= 

‘ -'dmalnt 1 .dmaSleep 

let dm a 

ss 

dmaSleep; ; 

let cpuDMACreate 

= 

1 -’cpuVriteReg* . - *cpuInitExec # ; ; 
* 'dmalnt * . cpuContinue 

let cpuDMAWait 

= 


Another example of rendezvous exists where a FPU must rely on the CPU for stores to 
and fetches from memory. Given an interleaved instruction stream, simultaneous execution 
by the two devices can occur; however, a rendezvous exists when results from one are needed 
by the other device. 


5.2 AVM-1 /MMU CONNECTION SPECIFICATION 


This section will describe the specification of a system consisting of the AVM-1 micropro- 
cessor and the MMU device verified in previous work (refs. 2 and 1). 
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5.2.1 AVM-1 


The AVM-1 processor is described in detail in (ref. 14) and will only briefly be described 
here. AVM-1 was designed to demonstrate the use of generic interpreters in verifying hier- 
archically decomposed microprocessor specifications. 

The design was motivated by the desire to provide hardware features that were not 
present in previous microprocessor verification efforts and would support a realistic operating 
system. In addition to vectored interrupts, AVM-1 supports a supervisor mode. AVM-1 
has a load-store architecture based on a register file consisting of: 

a. Register 0, which is read-only and contains the constant 0. 

b. Seven supervisor-mode registers including a supervisor stack pointer. These registers 
are read-only unless the CPU is in supervisor-mode. 

c. Twenty-four general purpose registers. 

A program status word register maintains the status of the last ALU operation, whether in- 
terrupts are enabled, and the privilege level of the currently executing process. The program 
counter is also visible at the assembly language programmer level. 

The instruction set contains 30 instructions and is similar to that of RISC I. For 
example the MOVE instruction is synthesized using an ALU operation. The instruction 
set is designed to support coprocessors. Six bits are reserved for the opcode. If the top 
opcode bit is high, the processor assumes the instruction is intended for a coprocessor. 


5.2.2 ABSTRACT MMU 

A description of a number of memory management units which form a complexity hierarchy 
appears in (ref. 2). By developing a sophisticated MMU in steps, the construction of the 
final proof appears to be more tractable. The simpler devices validate access to fixed length 
memory pages while the more complex devices authorize read, write or execute access to 
variable length segments and translate virtual addresses to real addresses. Many of these 
devices were designed and verified to the gate-level. However, as the complexity increases, 


40 



the emphasis of the verification shifts from gate level connections to the correctness of the 
operating-system support features. 

The abstract MMU validates memory requests based on information maintained in a 
memory- resident segment descriptor table. The location of the table is determined by a 
segment-table pointer register, which is accessible only during supervisor operations. Each 
descriptor consists of two words: the first contains access control information (present bit, 
read/ write /execute permissions, segment size) and the second serves as the base address for 
the segment’s real location in memory. To translate from a virtual address to a real address, 
the MMU adds the segment offset to the segment base address. The MMU assumes the 
table provides an entry for all possible segment descriptors. 


virtual address 


real address 

[ Segment Table Pointer 

data 


acknowledgement 

read/ write/exec ^ 

supervisor mode 




Figure 5.2-1: Abstract MMU Environment/State 

The abstract MMU representation generalizes traits particular to concrete implemen- 
tations. A generic theory for a class of MMU devices is defined where several functions 
and data types are left abstract. Using an abstract representation, details such as word 
length can be omitted and the verification focuses only on the correctness of higher level 
abstraction (e.g., electronic block level rather than gate level). Other properties such as the 
exact security policy and division of a virtual address into a segment identifier and offset 
are left unspecified. At a later point, the abstract representation can be instantiated with 
components that implement concrete behavior. 


41 




5.2.3 CPU MMU INTERACTION 



To determine how the CPU and MMU interact, we examine the external interface of AVM-1 
with memory and the interface that the MMU provides to the CPU. Below we show the 
AVM-1 memory interface specification. If a write request is made at time t the memory 
will reflect this request at time t + 1, otherwise, the memory will remain unmodified. If a 
read request is made at time t then the data value returned is a function of the memory 
contents at time t. 



This specification is incomplete for the purposes of connecting the CPU with the MMU. 
There is no external line to indicate the security status of an executing process (e.g., the 
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supervisor line); nor is there a return code indicating whether the memory request was 
validated. Additionally, the specification assumes that memory operations occur in a single 
cycle. This last consideration could be dealt with by an appropriate temporal abstraction. 

Below is a modified specification that includes these features. A security line is added 
to the specification and an acknowledgment variable (ack) is added to inform the CPU of 
invalid memory requests. This variable is set based on a new abstract function memMgt . The 
abstract CPU functions, store and fetch, now expect the supervisor state as an additional 
argument (superV). These functions should not perform as requested when security/safety 
requirements are not satisfied. 



With these additions, the process algebra term for this interface can be defined as below, 
cpu.write.request = ( userMode + r.superMode). write, address. data.(ack + nack) 
cpu.read.request = ( userMode + r.superMode). read. address.(ack + nack). data) 
CPUtoMEM = cpu_write_request + t. cpu.read.request 
CPU = CPUtoMEM. CPU 

These terms are abbreviations for their actual representations in HOL. The PREFIX 
operator is defined to construct an agent from an action and an agent rather than from two 
agents as presented here. 

Note the use of the internal operator to indicate that at given points, the CPU will 
behave in one of two ways: communicate through the userMode action or through the 
superMode action. This choice is made internally by the CPU. Without this use of r, the 
terms would mean that communication could occur by either action, depending on what an 
external agent might choose. This use of the r action can also be seen in the process algebra 
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terms for the MMU below. 


The MMU specification is in several parts as listed below. 


\- if , l«jralAcc«»s r vAddr tblPtr rw« mea * . 

l«t a * (latch r) (men, (address r)((add r) (segldshf r vAddr .tblPtr) ) ) in 
((validAccsss r) (vAddr ,a,rv«) A (olsLEq r) (vAddr, a)) 


h de/ vToR r vAddr tblPtr aaa * x ,, , . , , J 

lat a * (latch r) (aaa, (addraas r) ((add r)( (wordn r 1), 
(add r) (aagldshl r vAddr, tblPtr) ))) in 
(addraas r) ((add r) (sagOls r vAddr, a)) 


h de/ anparHoda r vAddr rwa tblPtrADDR tblPtr data aaa = 
((aBIT rva) A (addrEq r (vAddr.tblPtrADDR))) 

— ( T, vAddr, data ) I ( T, vAddr, tblPtr ) 


h de y user Hods r vAddr ma tblPtrADDR tblPtr data aaa — 
legalAccess r vAddr tblPtr rve aaa 

— » ( T, (vToR r vAddr tblPtr aen), tblPtr ) 

| ( F, vAddr, tblPtr ) 

, Baiu_apac r vAddr rwa tblPtrADDR tblPtr data aaa suparv = 
snparv — ♦ suparModa r vAddr rsa tblPtrADDR tblPtr data aaa 
I usarModa r vAddr rva tblPtrADDR tblPtr data aaa 


To express the notion that the MMU performs some work before responding, the r 
action is inserted before the response is returned. Part of this action may be to update the 
segment-table pointer value. While the system is able to accept either a userMode or a super- 
Mode communication, the MMU chooses to respond with only ^ or communication. 
The MMU specification also states when the MMU segment-table pointer is updated. This 
action is not relevant to the CPU -MMU interface, so it is expressed as an internal (r) 
action. This specification yields the process algebra terms: 

m m u _process_write = ( userMode -f super Mode), write . address . data .t .(ack -f T.nack) 

mmu_process.read = ( userMode + superMode).read.address.r.(ack + T.nack). data 
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MMUtoCPU = mmu_process-write + mmu.process.read 

MMU = MMUtoCPU. MMU 
System = CPU | MMU 




5.3 PROOF OF CORRECT COMPOSITION 


The agents CPU and MMU are recursively defined and exhibit an infinite behavior. To show 
that the composed CPU and MMU communicate correctly, we must show that the system 
is always able to return to its initial state. It is also necessary to show that progress is made 
when the CPU initiates a dialogue with the MMU. The proof goal then can be stated as: 

a. If either of the CPU actions, userMode or superMode, are enabled, the memory sub- 
system will engage in communication. 

b. The communication protocol will complete and the system returns to its initial state. 

To formalize and prove this goal in HOL, agent terms are defined based on the process 
algebra terms described in section 5.2.3. To reason about the finite protocol communication 
sequences, the recursive behavior of the agents is removed. The recursive agent reference is 
replaced with an (undefined) agent constant SUCCESS. 

In the box below, we show the construction of the MMU process algebra term 2 . The 
CPU term is defined in a similar manner. The term is constructed in parts by building up 
an ML string. The ML function Agent parses the ML string and returns a HOL agent 
term. ML strings are delimited by backquotes (‘) and the string concatenation operator is 
the caret symbol ('). 


let BULB = 

* ( ’ wr i t e ’ . ' addr dat a ack '. SUCCESS ) + ( T . - ' nack ’ . SUCCESS )))';; 
let mur = 

‘ ( ’read’ . ’addr* . ((-’ack* . ‘data* . SUCCESS) + (T. -'nack ’ . 'data' .SUCCESS))) * ; ; 
let blsb = 

* ( 'write*. ’addr’ . 'data’ . ((-’ack* .SUCCESS)+(T. -'nack' .SUCCESS))) ' ; ; 
let star = 

* ('read' . 'addr' . ((-'ack’ . ’data' . SUCCESS )+(T.-' nack' . 'data' .SUCCESS)))' ; ; 

let user.Bunu = '( 'user' .('* blub *' + '* mur “))';; 
let auper_mmu = '( 'super ’ .(“ blsb Bisr “))';; 

let bubu = user.aunu “+'* super.nunu *')';; 

let MMU = Agent bubu; ; 


2 As with many such definitions, it is perhaps easier to read the code from the bottom upwards. This 
gives the reader a top-down viewpoint. 
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To express the goal in a general form, several auxiliary definitions are defined. 


a. A recursive definition (ENABLED) is defined to construct a list of all output actions 
that an agent can perform. 

b. A new relation FLUX states that two composed systems are members of the re- 
lation only if a sequence of internal actions can be found to relate the first to the 
second. FLUX is similar to TRANS except that the laws TRANS.COM1 and 
TRANS-CO M2 are not present. 


c. A goal predicate definition BECOMES is defined. The predicate states that for all 
possible enabled output actions, a complement action exists such that a success agent 
is reached immediately or reached in a descendent. 


let ENABLED = new recursive-definition false AGENT 'ENABLED' 
"(EIABLED(IIACTIVE) • □) A ^ . , 

(ENABLED (PREFIX a A) = ( (INTERBAL=a) => EIABLED A I 

V (( (TYP a) - F) » M I □ ))> A 

(EIABLED (SUNN A B) * APPEND (ENABLED A) (ENABLED B>) A 

(ENABLED(CONPOSE A B) * APPEND (ENABLED A) (ENABLED B) ) ; ; 

let (FLUX rules, FLUX.ind) * let FLUX = »FLUX:agent->action->agent->bool" in 
new_ induct ive_def init ion false 'FLUX' ("‘FLUX x a y" , □ ) L 
X ACT LAV X 

[ ]. v 

••‘FLUX (PREFIX ay) ay" 

;X SUNL LAV X 
[ —FLUX x a y" 

X A 

"‘FLUX (SUNN x z) a y" 

; X SUNR LAV X 
[ —FLUX x a y" ] , 

X 

"‘FLUX (SUNN z x) a y" 

;X CON LAV X , 

[ "‘FLUX x (EXTERNAL (T,s)) x ,M ; 

"‘FLUX y (EXTERNAL (F,s)) y*" ]. 

% X 

"‘FLUX (CONPOSE x y) INTERNAL (CONPOSE x' y’) n 
;X RES LAV X 

[ — FLUX x ay"; _ 

— ( (LBL a) * (SID (r:label))) M ], 

X 

"‘FLUX (RESTRICT r x) a (RESTRICT r y) " 

;X TRANSITIVE LAV X 

[ "‘FLUX A a C"; 

"‘FLUX C a B" 

A J * 

"‘FLUX A a B" 

let BECOHES > new_def init ion ( 'BECONES' , 

”! (system success :agent). BECONES system success * 

(EVERY (\x. (FLUX system x success)) (ENABLED sys) )“);; 
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The success agent for the composed MMU-CPU is SUCCESS \ SUCCESS. By un- 
winding the agent definitions and using the FLUX laws, all possible paths are found to reach 
the success agent through internal transitions. The MMU-CPU composed communication 
proof shows that: 


1- BECOMES (CPU I MHU) (SUCCESS I SUCCESS) 


5.3.1 SYSTEM SPECIFICATION WITH A DMA DEVICE 

The DMA we present is based on the device verified in (ref. 32), which provides four channels 
between memory and I/O devices. The behavior of each channel is determined by a set of 
registers. For present purposes, we will consider a DMA with a single write-to-memory 
channel. The register set for a channel consists of: 

a. A counter register, which, when reaching zero, interrupts the CPU to indicate the 
channel has completed its task. 

b. A memory address counter, which must be initialized to the base address in memory 
for the block transfer. After each I/O transfer, this register is incremented. 

c. A control/status register, set by the CPU to activate a channel and unset by the DMA 
when the channel has completed its task. 

Two system configurations are possible. The DMA could reside between the CPU and 
the MMU or between the MMU and memory. The proposed system places the DMA before 
the MMU (see Figure 5.3-1 ). Thus, DMA writes to memory are validated by the MMU. 

The DMA will respond to three events: a read DMA register request, a write DMA 
register request, and an I/O device service request (once enabled). An I/O device service 
request requires that a value be written to memory and that when the channel counter 
reaches zero, the CPU be interrupted. Below we present the process algebra terms for this 
behavior. A more complete CPU agent is also defined to accept interrupts from the DMA. 

writeReg = write, address, data 
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CPU 


MMU 




fM 





DMA 


Figure 5.3-1: CPU/MMU/DMA System 


read Reg = read. address, data 

activelO — writeReg.DMA + readReg.DMA+ 

(iolnt .superMode. write .address, data, (ack + nack) 

DMA = writeReg + readReg + T.activelO 
CPU = (CPUtoMEM + r.cpulnt). CPU 


System = CPU | MMU | DMA 


Memory 


(DMA + r.cpu/nt.DMA) 
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6.0 CONCLUSIONS 


We have presented a framework to formally verify the correctness of communication 
between composed devices. Previous system verification research has developed vertically 
verified systems. However, the hardware bases for these systems have been simplistic. Our 
research is developing a framework to verify a more realistic horizontally verified system. This 
work demonstrates that CCS is a good choice for describing interdevice implementation-level 
connections within a computer system. Additional research will expand the calculus and ad- 
dress automating the derivation of process algebra expressions from interpreter specifications. 
Several improvements are being investigated, including: 

a. An additional type constructor for recursive agents. This constructor will be necessary 
to show the equivalence of infinite agents. 

b. Extending the calculus so that reasoning about the higher-level semantics of composed 
agents can be performed. 

c. Greater proof support. Many of the proofs performed appear fairly easy to understand 
outside of the formal model. As with most formal proofs, many details that appear 
trivial require a fair amount of work to verify. The pretty-parser and pretty-printer 
support are helpful; however, due to the underlying representation for agents, large 
terms must be manipulated by hand. The automation of more of the tedious aspects 
of the proof will allow formal reasoning about much larger examples to take place. 

d. Several extensions to the calculus are being examined, including the addition of a data 
field to all actions. With this addition, conditional operator constructs could be formed 
(e.g., if ( val > 5) then Agent = A else Agent = B). The addition of a labeled r 
action might also help in understanding the semantics of an agent. 
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